FIG. 1 is a basic block diagram of the overall system architecture in a standard computer system that requires coordination between updating of elements that may be changed by various components in the system. In FIG. 1, main frame 2 includes the overall programs and processes for implementing various programs, such as insurance premium programs, billing procedure programs, correspondence programs, address information programs, and the like. Main frame 2 is accessible via developer work station 4 for initiating changes to the main frame 2 programs stored therein.
Corporate workstation 6 utilizes some of the programs stored in main frame 2 for corporate purposes. Claim litigation office 7 accesses certain programs in main frame 2 via corporate workstation 6. The litigation office 7 may access all programs or a subset of programs via corporate workstation, depending on the need of the individual in claim litigation office 7. One or more insurance support centers (ISC) 8 receive information from, and transmit information to, main frame 2 for insurance requirements. For example, main frame 2 will transmit, on the instruction of a developer, recent program changes that affect the ISC 8. On the other hand, ISC 8 may transmit premium or customer information to main frame 2 to update customer records, outstanding obligations or even process claims. ISC 8 may be used to coordinate among a plurality of regional offices as described below, that perform similar functions as ISC 8. On the other hand, ISC 8 may be used to coordinate among the regional offices, and might not contain any substantive programs that relate to customer services.
Main frame 2 is also optionally connected directly to a regional office 12 for direct communications, in a similar manner as connected to ISC 8. Main frame 2 is also optionally connected to a public network, such as a standard public switched telephone network (PSTN) 10, for connection to regional office 14 and regional office 16 via ISC 8. Regional office 12 may include one or more work stations which allocate work based on individual, geographic area, or other criteria.
Regional office 12 is optionally connected to, for example, agent office 18 where agents are able to directly utilize the regional office 12 computer system. Regional office 12 may also be optionally connected to claim office 20 for processing customer claims/issues. Further, claim office 20 may, in turn, be connected to a second tier claim office 22 to provide a mechanism for claim office 22 to access the regional office computer system 12.
FIG. 2 is an illustration of the basic components of main frame 2. In FIG. 2, main frame 2 includes three basic components: support platform 26, production platform 28, and developer platform 30. Support platform 26 is used, for example, to load new programs, operating systems and the like, to evaluate its use for the entire computer system. Developer platform 30 includes development tools for creating and testing new development programs. Production platform 28 then distributes the developed and tested programs/elements for distribution to the necessary components of the system.
Developer platform 30 includes build issuance (BLDISS) component that receives element changes from a developer work station or host developer analyst. Build issuance 32 transmits the changes or modifications to post issuance (POSTISS) component 36 for distribution to down stream system components via corporate implementation system (CIS) 38 to the corporate system, generalized work station implementation system (GWIS) 40 to the developer work stations, and regional implementation system (RIS) 42 to the regional or ISC systems. Each of these components, as well as some additional components utilized in the prior art system, are described in detail below.
CMU: abbreviation for Change Management Utility. CMU is an interface to a vendor product called "PVCS" (Polytron Version Control System) that provides a method to manage changes to elements on the workstation.
BLDISS: abbreviation for Build Issuance. BLDISS is a dialog process used to enter the initial bookkeeping information for an element's issuance. It creates an Issuance Control Member (ICM) which stores information related to the issuance and implementation of an element. HP BLDISS performs BLDISS functions listed above for elements managed on an HP (Hewlett-Packard) system.
POSTISS: abbreviation for Post-Issuance. POSTISS is a system that collects and bundles elements for transmission to their production execution destination prior to their effective date.
RIS: abbreviation for Regional Implementation System. RIS is a dialog process which resides in the regional offices. Its primary functions include queuing transmitted elements to the appropriate staging libraries, verifying that elements are eligible for installation into production, and implementing those elements to the correct production libraries when requested. RIS requires manual intervention by an Issuance Technician to initiate any of its processes. A similar implementation system exists for HP to distribute and implement HP elements on the destined HP machines in the regional data centers.
CIS: abbreviation for Corporate Issuance System. CIS is an automated system for staging and implementing elements into the Corporate Data Center (CDC) production environment. A similar system exists for the HP Corporate Issuance System to distribute and implement HP elements on the destined HP machines in CDC.
GWIS: abbreviation for Generalized Workstation Implementation System. GWIS is a facility used to distribute and implement workstation elements. The vendor package AM:PM is used to communicate between the IBM host and IBM-attached workstations.
PRJINFO: a facility that allows customers to perform various change management functions on groups of elements within an Issuance Name. Among these functions are the ability to build and mark ready ICMs, cross-reference elements both in development and production (PRODXREF), move elements to the system testing environment (ANTSISS), sign-out elements to an issuance name, and associate elements to a user-id.
Cross-reference tools (CXREF): CXREF is a production element cross-reference utility on IBM. Production Cross Reference tools (PRODXREF) is the utility on HP which tracks both development and production cross-reference information.
Number Signout Facility (NUMBER): NUMBER is an IBM mainframe tool which allows application analysts and librarians to "sign out" element numbers needed for application development.
PI.P: abbreviation for Production Interface--Panvalet. PI.P is an interface to the production Panvalet libraries to retrieve, browse, or print element source.
PCF: abbreviation for Project Communication Facility. PCF allows Corporate analysts to access Implementation Memos (IM), Coordination Control Members (CCM), and Special Communications (SC) built in BLDISS and sent to any data center.
The following described one or more of the above components in greater detail. The major functions and their descriptions are listed below. Before a component can be implemented, it must be processed through the issuance flow.
BLDISS is an interactive facility used to initiate the issuance process. Information is entered by the issuing analyst and stored into an ICM and placed on an ICM PANVALET. The BLDISS facility is an application which contains four functions:
A. Build and edit allows the entering of information which is needed to initiate an issuance. It contains a build and edict mode and will allow for a WEEKLY (cutoff Monday for implementation the following Monday), DAILY (requires 2 days lead time for implementation), EMERGENCY (to be implemented A.S.A.P.), DUMMY (secures components and produces analyst and shopwide documentation) and DUPLICATE (for advance pilot testing). The facility supports four types of issuances. They are as follows:
Type 1--Program
Type 2--Message
Type 3--Dynamic Table
Type 4--Security Profile
Of the four types, Programs require the use of a program linkdeck which can contain Audits, Images, Segments, Tables, and the Program source. The other three require only the source member.
B. Status change allows an item to be changed from "NOT READY FOR ISSUANCE" to "READY FOR ISSUANCE".
C. Display will allow browsing or printing of formatted issuance information.
D. Directory List will allow for a listing of components that have issuance information built for them.
The issuance processor is a background job that will perform the following tasks to transfer a program (e.g., a ADF program, and the like) and all of its components from a test to production environment. The issuance processor is a batch job submitted from BLDISS when a component is marked "ready for issuance". The purpose of this job is to generate the proper load code and store the load and source into a secured production library. Documentation and audit trails are also produced at this time.
A. Update issuance status dataset to indicate the issuance processor is running.
B. Retrieve the issuance control member from the production PANVALET library.
C. Retrieve the component from the appropriate area PANVALET library.
D. For the different components the following things happen:
AUDIT--The audit is retrieved from the area PANVALET to a dataset. It is then compiled, loaded and retrieved to create a static load module. PA1 STATIC TABLE--The table is retrieved from the area PANVALET to a dataset. It is then loaded and retrieved to create a static load module. PA1 IMAGE--The image is retrieved from the area or production PANVALET to a dataset and aliased for generic reference within the program. It is then used as input to program generator. PA1 SEGMENT--The segment is retrieved from the area or production PANVALET to a dataset and aliased for generic reference within the program. It is then used as input to program generator. PA1 PROGRAM--The program is retrieved from the area PANVALET to a dataset and then used as input to program generator. PA1 MESSAGE--The message is retrieved from the area PANVALET to a dataset. It is then loaded. PA1 DYNAMIC TABLE--The table is retrieved from the area PANVALET to a dataset. It is then loaded. PA1 SECURITY PROFILE--The profile is retrieved from the area PANVALET to a dataset. It is then loaded. (Components are implemented to the appropriate destination load library, or separately. The source is sent to the appropriate destination and used as input to the database update job.) PA1 1. Component--Individual fiche for each audit, table, message or profile issued and the corresponding sysprint from the gen or load. PA1 2. Linkdeck--A fiche containing the issuance control sheet, data dump, audit trail along with the linkdeck and a source only listing of each component in the linkdeck whether it was issued or not. PA1 Need for much redundant data entry PA1 Difficulty of adding new element types, sometimes as high as 1000+ analyst hours PA1 Inflexibility in how new element types can be added, they must follow the formats previously defined PA1 Data capture "after the fact" when all development is done PA1 Reduce redundant data entry; PA1 Capture data at the point where it makes sense to capture it; PA1 Enforce standards throughout the development cycle instead of at the end; PA1 Move responsibility for the data entry and its accuracy to the analyst responsible for the element; PA1 Derive as much information from current sources as possible (example: fabricate analyst information by accessing Department Code tables using IDs); PA1 Provide analysts with better grouping mechanisms in order to facilitate the move of elements into production in a more logical order; PA1 Eliminate some current data entry fields that have been deemed obsolete but have not been removed from the current system; and/or PA1 Provide analysts with better feedback concerning errors and standards violations. PA1 Minimizes the risk of overwriting changes made by another developer; PA1 Tracks the changes in archives and makes them easily accessible; PA1 Allows the creation of a copy of an element at any point in its development history; PA1 Allows the management of changes made to files on several platforms; and/or PA1 Allows the access of files across platforms.
E. If step D above completes successfully, transfer the appropriate source members to production and inactivate them from the area PANVALET.
F. Produce analyst audit trail containing a description of the data movement accomplished by the processor, the issuance control sheet, and the issuance data dump.
G. Store all of the output needed for the production of microfiche to the staging documentation library.
H. Update the user code of the issuance control member and the issuance status dataset to indicate ready for documentation.
A facility is also provided used by issuance administration to select components to be sent to the proper destination for implementation. The ICMs and load are "customized" (copied into a dataset with other components going to that same destination). The regional components are transmitted (using teleprocessing lines) while the corporate components are copied into datasets.
In addition, to BLDISS and POSTISS, a Documentation Processor is provided that is a nightly job that performs the following functions:
A. Gather issuance unit documentation for all issuance processors that processed that day.
B. Gather information for the following analyst microfiche:
C. Generate data to update the shopwide cross-reference dataset.
D. Update the user code of the issuance control member and the issuance status dataset to indicate issuance is complete.
Implementation of components is controlled through the use of Issuance Control Members (ICMs). Each component that is staged for implementation is accompanied by a corresponding ICM. The ICMs are stored on a PANVALET library and contain all of the information necessary to implement a component at the proper time in the proper place. ICMs are built by issuing analysis during an interactive issuance session called BLDISS. Any component that has been added to the BLDISS system will have ICMs.
The PANVALET user code and date field in the comment controls the automatic selection of components for the staging and implementation processing. ICMs that are staged for emergency processing have a different user code than non-emergencies. The functional or system destination is contained in the ICM. At implementation time, a code in the ICM determines which functional destinations the component is implemented to. The exact complex, system, and library to implement to is controlled by referencing a target library control dataset.
FIGS. 3-4 are flowcharts of the basic flow or process of updating element changes in the prior art system architecture. In FIGS. 3-4, PI.P stores most of the elements that analysts use for development purposes. PI.P stores various programs, modules, components, and various other types of elements. Analysts utilize PI.P to browse, print, retrieve, and the like, elements stored therein in step S2. Analysts are not required to identify the specific library storing the element.
Analysts then retrieve the elements, alter or change the element, and test the changed element in step S4. Once the analyst is satisfied with the changed element, the limited number of modified elements are stored on an area panvalet in step S6. Issuance information about the changed element is provided to a librarian on a sheet of paper in step S8. The librarian creates the ICM indicative of the changed element using BLDISS in step S10, and further all the issuance information associated with the changed element. The basic information entered by the librarian includes what element needs to be issued, who is issuing the element, when does the element need to be issued, and where does the changed element need to go for update purposes and why.
The analyst generally has the responsibility to do the actual software development, and the librarian is a clerical-type person that enters the specific element change information in the appropriate system, e.g., BLDISS. Thus, the analyst is the person who alters the element, and the librarian is the person who stores the data entry. The librarian uses BLDISS in step S10 to enter all the who, what, where and why information about the changed element. Once testing is completed, the element is stored on the area panvalet and the librarian creates the ICM, the librarian marks the ICM ready using BLDISS in step S12. The element source code will then be put into production via invocation of POSTISS in step S16. POSTISS creates executables for the source code, and distributes the executables as required in step S18.
Note that the source and the executable versions of the changed element can be one in the same, depending on the element type. Several times throughout the day and in the evening POSTISS is invoked to process elements including programs that have successfully gone through the issuance processor. POSTISS picks up the program load that is ready to be transmitted, and bundles it according to destination and transmits the bundles over the teleprocessing lines. For example, if program P-1,2,3,4 is to be distributed to all 28 regions, POSTISS puts together 28 bundles and send that one program across to 28 different destinations.
After the element is distributed by POSTISS, the element is moved into production and used to change the elements requiring updating in step S20. There are three separate modules which are supporting three separate entities. RIS supports distribution for the regional office or Insurance Support Center, CIS supports distribution for the corporate office, and GWIS supports distribution for the developer workstations.
If it is determined in step S22 that the element to be changed is for the regional office or ISC, the changed element is transmitted to the regional GWIS system in step S24. The PC technician uses the work station implementation system GWIS in step S26 to access a file to schedule the element change to the work stations and/or network servers.
FIG. 5 is a flow chart of the processes utilized by a work station developer. In FIG. 5, the work station developer initiates a directory level request with all elements in executable form to be changed or modified in step S28. A workstation developer who wants to issue a workstation component or element can also issue an element at the directory level in step S30. The developer accesses the BLDISS system as described above and indicates the directories where the executable elements are being stored, and which directories the elements are being updated for implementation. Thus, the work station developer is able to group together one or more elements to be downloaded into the destination systems. The developer indicates a directory on a workstation from which an element is to be issued.
Pre-install and post-install commands may optionally be specified to assist POSTISS in moving the designated elements into production. The data issuance information is uploaded to the host using generally one file, along with the pre-install or post-install information in step S32. The administrator workstation accesses the files, schedules the element changes for the workstation or groups of workstations as described above.
The following is a specific example of the use of updating elements in the existing computer system when the elements are, for example, dataset documents via the Automated Document Issuance System. The Automated Document Issuance System consists of two interactive systems. The first system is the Document Build Facility, BLDDOC, and the second is the Documentation Automated Security and Issuance System under BLDISS. Dataset document are created in BLDDOC and are issued through BLDISS. The interactive systems have been developed to provide:
1. A method to build, browse, and obtain a hardcopy of a dataset document interactively.
2. A method to issue and secure a dataset document.
3. A method to help enforce dataset documentation standards.
4. To create an audit trail of a dataset document issuance.
The following describes the procedures for building a dataset document through BLDDOC. There are three categories of dataset documentation, HP files, IBM datasets, and IBM VSAM datasets. Each type of document has a slightly different interactive session to building the document. The name of dataset documents consists of two parts. The first part is the filing key which can be up to 15 characters long. The second part is the version. This takes the form `ANN` where `A` represents an alphabetic character and `N` represents numeric characters. The version of a production document must be incremented when it is revised and reissued.
The data item to be edited is selected by typing an `S` in the selection field of the edit item table and hitting the `ENTER` key. A prompt is generated to enter data through one or more panels. In the majority of the panels the `ENTER` key is used to save the data entered. If the `END` (PF15) key is used, any new or changed data will not be saved. The exceptions to this are free form edit items (i.e., data entered through SPF edit) and panels which use a DMS table for input (e.g., Job References). The `END` key is used to store data for these exceptions.
A new document may be built using an existing document as a model provided the type of the model matches the type of the document to be built (e.g., an IBM VSAM document cannot be built using an HP document as a model). All dataset types have required information that must be entered before a document can be considered valid. Unlike BLDISS, BLDDOC does not force all of the required data to be entered in one edit session. The document is saved and the edit session ended without entering all of the required data. When the document is saved, it is stored in a `COMPLETE` or `NOT COMPLETE` status. A document is considered `COMPLETE` if all the required data items have been entered. It is considered `NOT COMPLETE` if at least one of the required edit items has not been entered.
BLDDOC checks to see if a document is complete when saved. If it is not complete, a screen will appear listing the edit items that still need to be entered. BLDDOC will also check to see if the document is complete when edited. An asterisk (*) will appear next to the item description in the edit item table when the item is required and still needs to be entered.
The following edit items are required for an IBM dataset:
a. Name/Desc/Prod Area--(includes: dataset name, dataset description, production area, data owner, and data sensitivity).
b. Jobs References
c. DCB Attributes
d. Medial Type
e. Catalog Considerations
f. Retention
g. Record Formats
The following edit items are required for an IBM VSAM dataset:
a. Name/Desc/Prod Area--(includes: dataset name, dataset description, production area, data owner, and data sensitivity)
b. Jobs References
c. DCB Attributes
d. Record Formats
The following edit items are required for an HP file:
a. Name/Desc/Prod Area--(includes: file name, file description, production area, data owner, and data sensitivity)
b. Jobs References
c. File Attributes
d. Media Type
e. Record Formats
f. Retentions
The following describes the procedures for issuing a dataset document through BLDISS. The name and version of the Issuance Control Member (ICM) built through BLDISS must match the name and version of the document to be issued. Duplicate issuances are the exception to this. A duplicate version must take the form of `ANNA` where `A` is an alphabetic character and `N` is a numeric character. The `ANN` part of a duplicate version must match the version of the document to be issued as a duplicate.
Dataset documents are issued through the Build/Edit section/function. Enter the name and version of the document to be built or edit and hit enter. The analyst name panel is then displayed. Enter the data in the analyst name panel and hit `ENTER` to get to the edit item selection list. Select the items to be edited, or hit `END` and a prompt is displayed for all of the required items that need to be entered.
The following items appear in the edit selection list:
a. Project Information Required b. Destination Required c. Implementation Date Required d. Transmission Dataset Not Required e. Coordination Not Required f. Dataset Cluster Required when the destination is corporate g. Reason for Issuance Required h. Comments Data Processing Not Required i. Commments Issuance Unit Not Required
A new ICM is built using any existing ICM as a model. This includes using a duplicate as a model. A duplicate ICM cannot be built if:
a. The document to be issued as a duplicate has not been created or stored in a `Not Complete` status.
b. The original version of the ICM does not exist (e.g., the duplicate ICM cannot be built if the original ICM does not exist).
To issue a dataset document as a pilot, build the ICM for the document new and issue it to the pilot destination. Any further issuances of the same document to additional destinations after the pilot can be duplicate.
Regional Support production is a valid destination for document issuances. Regional Support Test issuances is not a valid destination. Therefore, any document to be used for Regional Support should be built through BLDDOC, printed to hardcopy and sent to Regional Support. Regional Support will also be able to print off a hardcopy of the document through BLDDOC. An Issuance Control Member may be built for the document through BLDISS, but do not generally mark it "READY FOR ISSUANCE". By not issuing the document it will remain in a test status and can still be edited. The document may be marked "READY FOR ISSUANCE" when the testing is complete and the document is ready for production.
When a dataset document is complete and the ICM has been created the Issuance Processor may be submitted through BLDISS. The Issuance Processor is submitted by marking an ICM "READY FOR ISSUANCE". A document cannot be marked "READY FOR ISSUANCE" if it is in a `NOT COMPLETE` status. The Issuance Processor will:
a. Create an audit trail of the issuance.
b. Verify that the document meets as many standards as possible.
c. Print an Issuance Memo and Issuance Control Sheet for Issuance Administration.
d. Print a Data Dump of the ICM for the person who created the ICM.
e. Print a sign off sheet to be signed by the dataset owner. This will be routed back to project coordinator listed for the document. The sign off sheet will be created only when the dataset is a new dataset or when an existing dataset whose retention information has changed.
The Issuance Processor will validate the following items:
a. A Vital or Disaster dataset must not have disk as a media type.
b. Only one cluster is allowed for Vital or Disaster datasets with a corporate destination. The cluster is used to update corporate Vault Pattern Dataset.
c. The destination of ICM must agree with the location of the dataset specified on the document.
d. If the location specified on the document is corporate only or regional only, differing information is not allowed.
e. If a dataset is a preallocated disk dataset, space allocations must be specified.
There is a "Validate Document" facility in both BLDISS and BLDDOC. This facility may be used to precheck any document for the errors specified above. The facility produces an audit trail outlining the success or failure of the validation.
The responsibilities of the user of the Dataset Documentation Automation Systems are to review the audit trail from the issuance processor. This audit trail will be returned to the analyst or librarian that built the ICM in the Document Issuance Facility. It will be the responsibility of this person to recognize whether a document was issued successfully or encountered an error. If an error occurred, appropriate changes must be made and the component must be remarked "READY FOR ISSUANCE".
Issuance Administration will serve as a point of control to answer any questions regarding errors encountered in the issuance process. The project coordinator will be responsible for returning the sign off form to Issuance Administration.
The responsibility of Issuance Administration is to serve as a point of control to answer any questions regarding dataset document issuances. Issuance Administration will review the dataset document when it is marked ready to ensure the document meets standards. If the document is in error, the issuing analyst will be notified of the error and will be instructed to correct it.
As can be readily seen, the procedure for implementing dataset document changes is quite complex and involved. The prior art system requires entering data on multiple screens. The data that is entered is gathered after analysis, design, and testing have taken place. It is required that the same data be entered multiple times if multiple elements are being issued for the same project.
The data is captured and stored in a format known as the Issuance Control Member (ICM). This member consists of strings of data concatenated together through the use of special symbols and item identifiers. This storage method is a carry-over from when the ICM information was stored in strings on Panvalet. The ICM is stored in a `not ready` status until the analyst determines the element(s) are ready to be placed into production. At that time, the ICM is marked `ready.`
An issuance processor job runs in batch mode on the Devplex. If the issuance processor job is successful, then the process to distribute the element is initiated. If it is unsuccessful, it is up to the analyst to determine why the issuance failed, fix the problem and mark the element `ready` again. This cycle continues until the issuance is successful and the process to distribute the element is initiated.
The information for the data is provided to the librarians by the analysts in various ways, including writing on hardcopies of data dumps (copies of previously entered ICMs) and sending the information through e-mail. The data capture is typed in manually by librarians. Very little of the information is derived from outside sources. The librarian may, however, use a `model` (previously built ICM) to bring some information forward for a new ICM. There are restrictions on what information can be brought forward from a model, requiring some data entry for every new ICM.
If more than 3 related elements are to be issued, a Coordination Control Member (CCM) is used to make sure the elements are grouped and sent to the same implementation sites at the same time. Again, there is much duplicate data entry of information between the ICMs and the CCM. Verification of the data entered about the implementation sites and the implementation dates is a very complex process that can be accomplished by the librarian submitting an audit before the elements are marked ready. The process is also invoked when the CCM is marked ready to ensure that all the elements share the same implementation sites and dates and also that all components contained in the CCM have successfully completed that first phase of the issuance process.
Enforcement of many standards is done when the issuance processor job runs. If any standards violations are encountered, the job is aborted. There are very few ways for the analysts to verify that they are meeting the standards when they are in test mode except to compare their element to the documentation in the DPM (Data Processing Manual) to ensure they are meeting standards.
Accordingly, we have identified the following shortcomings of the current system:
Accordingly, it is desirable to design a computer architecture and process for overcoming the above shortcomings, as described in detail below.